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DETAILED ACTION 

This non-final rejection is in response to Applicant's request for continued examination 
filed on 12/21/2009. Applicant amends claims 1, 2, 5, 10, 15, 17-19, 21, 25, 30, 32, 37, 41, 42, 
and 47, cancels claims 3, 4, 1 1, 22-24, 26, 31, 38-40, 43, and previously cancelled claims 51-58 
and 61-66. Accordingly, claims 1,2, 5-10, 12-21, 25, 27-30, 32-37, 41, 43, 44-50, 59, 60, and 
67-85 are presented for further examination. 

I. Continued Examination Under 37 CFR 1.114 

A request for continued examination under 37 CFR 1.1 14, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 12/21/2009 has been entered. 

II. Response to Arguments 

Applicant amends the independent claims to recite two new limitations (1) receiving an 
aggregated reply packet from the peer aggregation device, wherein the aggregated reply packet 
indicates the status of at least some of the plurality of PPP sessions, wherein content of a local 
status table is updated with the status of the PPP sessions, which have the aggregation device as 
an endpoint; and (2) sending a proxy keep-alive reply message to one of the plurality of end 
systems originating a corresponding one of the keep alive-messages without waiting for the 
aggregated reply packet to be received. 
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With the exception of the limitation "wherein content of a local status table is updated 
with the status of the PPP sessions," both of these limitations were already rejected in the 
previous rejections as set forth by the previous examiner. 

1. Applicant's arguments are not persuasive because they do not address the 
previous art rejections . 

Applicant's arguments therefore fail to comply with 37 CFR 1.1 1 1(b) because they 

amount to a general allegation that the claims define a patentable invention without specifically 

pointing out how the language of the claims patentably distinguishes them from the references. 

The first "new" limitation is similar to the limitations found in claim 2 and almost identical to the 

limitation of cancelled claim 3. The second "new" limitation is almost identical to the limitation 

of cancelled claim 4. 

The examiner notes that Applicant in the arguments filed on 12/21/2009 also do not 
address the specific citations and instead rely on the conclusory statement that Applicant "finds 
nothing that would be pertinent to teach teachings." 

2. Ketcham and Pereira substantively teach the first new limitation as 
evidenced by the rejection of claim 2 and cancelled claim 3 . 

Claim 2 recites "receiving said aggregated request packet in said peer aggregation device, 
indicating the status of said plurality of sessions in the aggregated reply packet, and sending said 
aggregated reply packet to said aggregation device." Cancelled claim 3 recites "receiving in said 
aggregation device an aggregated reply packet from said peer aggregation device, wherein said 
aggregated reply packet indicates the status of at least some of said plurality of PPP sessions." 

The examiner notes that in its decision rendered on 10/23/2009, the Board of Patent 
Appeals and Interferences did not overturn the rejection of claims 2-4. In upholding the rejection 
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for claim 2, the Board stated that "we find no support for the contention that the Examiner's 
proffered combination of Ketcham and Pereira would not have a reasonable expectation of 
success" [Board decision, Appeal 2008-005300, pg. 7, ](3]. Applicant did not present any 
arguments as to claim 3 so it fell with claim 2. 

Because Applicant does not point out why the cited portions of the references fail to 
teach the limitations as described in cancelled claim 3, Applicant's argument is not persuasive. 
The examiner maintains that Pereira discloses "receiving in said aggregation device an 
aggregated reply packet from said peer aggregation device, wherein said aggregated reply packet 
indicates the status of at least some of said plurality of PPP sessions" {Pereira, col. 6, lines 1-6). 

3. Ketcham and Pereira teach the second new limitation as evidenced by the 
rejection of cancelled claim 4 . 

In upholding the rejection of claim 4, the Board stated that Applicant did not specifically 

address the prior art citations set forth in the rejection. Because Applicant does not point out 

why the cited portions of the references fail to teach the limitations as described in cancelled 

claim 4, Applicant's argument is not persuasive. The examiner maintains that Pereira discloses 

the step of "sending from said aggregation device a proxy keep-alive reply message to one of 

said plurality of end systems originating a corresponding one of said keep alive-messages 

without waiting for said aggregated reply packet" (Pereira, column 5, lines 45-47). 

4. The rejection submits a new reference to disclose the limitation of 
"wherein content of a local status table is updated with the status of the 
PPP sessions, which have the aggregation device as an endpoint." 

The limitation does introduce a new limitation not found in either claims 3 and 4. 

Applicant's arguments are moot in view of the new ground of rejection to address to this new 

limitation. 
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III. Specification 

The specification is objected to as failing to provide proper antecedent basis for the 
claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the 
following is required: the specification does not provide antecedent basis for "computer readable 
medium" as claimed in claims 37, 41, 42, 44-46, 73-75, 84, and 85. The specification only 
describes the use of a "memory medium." Applicant should amend the claim to recite the term 
that is supported by the specification. 

IV. Allowable Subject Matter 

Claims 5-7, 17-20, and 41 are objected to as being dependent upon a rejected base claim, 
but would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 

V. Claim Rejections - 35 USC § 101 
35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

A. Claims 37, 41, 42, 44-46, 73-75, 84, and 85 are rejected under 35 U.S.C. 101 
because the claimed invention is directed to non-statutory subject matter. 

Claims 37, 41, 42, 44-46, 73-75, 84, and 85 are directed to a computer readable medium. 

As noted above, Applicant's specification provides no description for this term and therefore the 

term is given its broadest reasonable interpretation. The broadest reasonable interpretation of 
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"computer readable medium" typically covers forms of non-transitory tangible media as well as 
transitory propagating signals per se. 

Applicant may generally overcome this interpretation by clearly defining what is meant 
by "medium" and limiting the term to only non-transitory embodiments. However, merely 
providing examples (e.g., " medium may include memory, floppy disks, RAM, ROM. . .") is not 
the same as limiting the interpretation to particular embodiments. 

To overcome this rejection, Applicant should amend the claim to include the term "non- 
transitory" so as to insure that the medium is interpreted to include only statutory embodiments 
of a medium. However, as the claims are currently written, the "medium" may be interpreted as 
including both statutory and non-statutory embodiments and therefore is rejected under § 101. 

VI. Claim Rejections - 35 USC § 1 12 

The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

A. Claims 1, 10, 15, 21, 25, 30, 37, 42, and 47 are rejected under 35 U.S.C. 112, 
second paragraph, as being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. 

Claims 1, 10, 15, 21, 25, 30, 37, 42, and 47 lack proper antecedent basis for the term "the 

status". For example, claim 1 refers to "the status of a corresponding PPP session," "the status of 

said PPP sessions," "the status of at least some of the plurality of PPP sessions," and "the status 

of the PPP sessions." Claim 1 alone seems to refer to four different "statuses." If this is the 

case, then Applicant should use the traditional nomenclature for differentiating between the 

different "statuses" (e.g., a first status, a second status, etc. . .). If however they are referring to 
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the same status, then Applicant should amend the claim to provide more clarity. Similar remarks 
apply to the other independent claims. 

Claims 42 is also rejected for containing confusing claim language. The new limitation 
which starts with "receiving an aggregated reply packet from the peer aggregation device. . ." is 
confusing because of the term "an aggregated reply packet." There is already an "aggregated 
reply packet" claimed in the previous limitations. Therefore, it is unclear whether the term in the 
new limitation is intended to refer to the same aggregated packet or a second packet. 

Appropriate correction is required. 

VII. Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

A. Claims 1, 2, 8-10, 14-16, 21-23, 25, 29, 30, 35-37, 42, 46-50, 59, 60, 69, 72, 75, 
and 78-85 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Ketcham (U.S. Patent Number 6,721,334) in view of Pereira (U.S. Patent 
Number 5,781,726), in further view of Elliot, U.S. Patent No. 6.775.709. 

Claims 1, 21, and 37 

Ketcham as modified by Pereira and Elliot discloses a method of processing a plurality 
of keep-alive messages generated by a corresponding plurality of end systems, each of said 
plurality of keep-alive messages being designed to request the status of a corresponding point to 
point (PPP) session implemented on a communication network, said method comprising: 
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receiving in an aggregation device (Ketcham, figure 4, item 308) said plurality of keep- 
alive messages (Pereira, column 4, lines 31-34); 

generating in said aggregation device an aggregated request packet which includes data 
indicating that the status of said PPP sessions is requested (Ketcham, column 7, line 62 through 
column 8, line 4, wherein the aggregated packet contains poll requests as disclosed by Pereira); 

sending said aggregated request packet to a peer aggregation device (Ketcham, figure 4, 
item 314); 

receiving an aggregated reply packet from said peer aggregation device, wherein the 
aggregated reply packet indicates the status of at least some of said plurality of PPP sessions 
(Pereira, column 6, lines 1-6), wherein content of a local status table is updated with the status of 
the PPP sessions, which have the aggregation device as an endpoint [Elliot, column 4 «lines 9- 
16» | column 5 «lines 15-22»: combining plural status messages into a single update message 
that is broadcast to other routers where the router is an endpoint of the link (i.e., session) to 
another router where each router represents an aggregation device which update their local 
routing tables]; and 

sending from said aggregation device a proxy keep-alive reply message to one of said 
plurality of end systems originating a corresponding one of said keep alive-messages without 
waiting for said aggregated reply packet (Pereira, column 5, lines 45-47). 

As noted above, although Ketcham describes a system in which different types of data 
packets can be aggregated together, he did not explicitly disclose (1) the use of a keep-alive 
message or poll request; (2) receiving an aggregated reply packet from said peer aggregation 
device, wherein the aggregated reply packet indicates the status of at least some of said plurality 
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of PPP sessions; (3) wherein content of a local status table is updated with the status of the PPP 
sessions, which have the aggregation device as an endpoint; and (4) sending from said 
aggregation device a proxy keep-alive reply message to one of said plurality of end systems 
originating a corresponding one of said keep alive-messages without waiting for said aggregated 
reply packet. However, all four features were well known in the art at the time of Applicant's 
invention as evidenced by Pereira and Elliot. 

1. Pereira discloses the first, second, and fourth missing limitations. 
Pereira' & system is focused on the polling of point-to-point devices and explicitly states 

the use of a poll request from a first to a second end system and a poll response from the second 
to the first end system. Pereira further discloses receiving an aggregated reply packet from said 
peer aggregation device, wherein the aggregated reply packet indicates the status of at least some 
of said plurality of PPP sessions and sending a proxy keep-alive reply message to one of said 
plurality of end systems originating a corresponding one of said keep alive-messages without 
waiting for said aggregated reply packet. 

It would have been obvious to one of ordinary skill in the art at the time of the applicant's 
invention to modify the system of Ketcham by adding the ability to use keep-alive messages as 
the data packets as provided by Pereira. Here the combination would satisfy the need for an 
improved connection oriented protocol for systems that maintain a number of end users that 
share a common link. See Pereira, column 4, lines 12-17. 

2. Elliot discloses the third missing limitation . 

Elliot discloses updating a topology map which is similar to a status table representing 
the status of sessions between routers in the network. Elliot further discloses a router that 
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combines all status messages into a single update message which is then sent to all other link- 
connected routers which then update their local routing databases (i.e., table). It would have 
been obvious to one of ordinary skill in the art to have modified Ketcham's system to include the 
update message aggregation feature taught by Elliot. One would have been motivated to modify 
Ketcham in this manner because Elliot discloses that combining the updates into a single 
message speeds up propagation of the network information [column 7 «lines 34-37»]. 

As to claims 21 and 37, they are merely claims to an aggregation device and medium that 
implement the steps of the method of claim 1 . Claims 21 and 37 are rejected for at least the 
same reasons set forth above. 

This rationale also applies to the independent and dependent claims utilizing the same 
combination. 

Claim 2 

Ketcham as modified by Pereira and Elliot discloses the method of claim 1 , further 
comprising: 

receiving said aggregated request packet in said peer aggregation device (Ketcham, 
column 8, lines 15-22); 

indicating the status of said plurality of sessions in the aggregated reply packet (Pereira, 
column 6, lines 1-6, wherein Pereira' s response polls may be aggregated at Ketcham's router 
314); and 

sending said aggregated reply packet to said aggregation device (Ketcham, figure 4, 
inherently data packets can also flow from router 3 14 to router 308). 
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Claim 8 

Ketcham as modified by Pereira and Elliot discloses the method of claim 1 , wherein said 
communication network is implemented using one of frame relay, ATM and IP networks 
{Ketcham, column 1, lines 33-48). 

Claim 9 

Ketcham as modified by Pereira and Elliot discloses the method of claim 1 , wherein said 
aggregation device is one of a network access server and home gateway {Ketcham, column 4, 
lines 37-43). 

Claims 10 and 25 

Ketcham as modified by Pereira and Elliot discloses a method of processing an 
aggregated request packet in an aggregation device, wherein said aggregated request packet is 
received from a peer aggregation device and indicates that the status of a plurality of point-to- 
point sessions is requested, said method comprising: 

examining said aggregated request packet to determine that the status of said plurality of 
point-to-point sessions is requested {Ketcham, column 8, lines 15-22, wherein the aggregated 
packet contains the poll requests as disclosed by Pereira); 

determining the status of each of said plurality of point-to-point sessions {Pereira, 
column 6, lines 1-6 and 50-55); 

generating an aggregated reply packet indicating the status of said plurality of point- to- 
point sessions {Pereira, column 6, lines 1-6, wherein Pereira's response polls may be aggregated 
at Ketcham' & router 314); and 
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sending said aggregated reply packet to said peer aggregation device (Ketcham, figure 4, 
inherently data packets can also flow from router 314 to router 308), wherein the aggregated 
reply packet indicates the status of at least some of the plurality of PPP sessions (Pereira, 
column 6, lines 1-6), wherein content of a remote status table is updated with the status of the 
PPP sessions, which have the peer aggregation device as an endpoint [Elliot, column 4 «lines 9- 
16» | column 5 «lines 15-22»: combining plural status messages into a single update message 
that is broadcast to other routers where the router is an endpoint of the link (i.e., session) to 
another router where each router represents an aggregation device which update tables remote 
from the routers], and wherein a proxy keep-alive reply message is sent to one of the plurality of 
end systems originating a corresponding one of the keep alive-messages without waiting for the 
aggregated reply packet to be received [Pereira, column 5, lines 45-47]. 

See rejection of claim 1 for reasons to combine Ketcham with Pereira and Elliot. 

As claim 25 is merely a claim to an aggregation device that implements the steps of the 
method of claim 10, claim 25 is rejected for at least the same reasons set forth above. 

Claim 14 

Ketcham as modified by Pereira and Elliot discloses the method of claim 10, wherein 
said aggregation device comprises one of a network access server (NAS) and a home gateway 
implemented in a communication network (Ketcham, column 4, lines 37-43). 

Claim 15 

Ketcham as modified by Pereira and Elliot discloses an aggregation device for 
processing a plurality of keep-alive messages generated by a corresponding plurality of end 
systems, each of said plurality of keep-alive messages being designed to request the status of a 
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corresponding point to point (PPP) session implemented on a communication network, said 
aggregation device comprising: 

an input interface receiving said plurality of keep-alive messages (Ketcham, figure 4, 
item 308 and Pereira, column 4, lines 31-34); 

a message aggregator coupled to said input interface, said message aggregator examining 
said plurality of message and generating data according to a format indicating that the status of 
said PPP sessions is requested (Ketcham, column 7, line 62 through column 8, line 4, wherein 
the aggregated packet contains the poll requests as disclosed by Pereira); and 

an output interface sending an aggregated request packet on said communication network 
to a peer aggregation device, said aggregated request packet containing said data generated by 
said message aggregator (Ketcham, figure 4, item 314), wherein the aggregation device is further 
configured to receive an aggregated reply packet from the peer aggregation device [Ketcham, 
column 8, lines 15-22], wherein the aggregated reply packet indicates the status of at least some 
of the plurality of PPP sessions [Pereira, column 6, lines 1-6)], wherein content of a remote 
status table is updated with the status of the PPP sessions, which have the peer aggregation 
device as an endpoint [Elliot, column 4 «lines 9-16» | column 5 «lines 15-22»: combining plural 
status messages into a single update message that is broadcast to other routers where the router is 
an endpoint of the link (i.e., session) to another router where each router represents an 
aggregation device which update tables remote from the routers], and wherein a proxy keep-alive 
reply message is sent to one of the plurality of end systems originating a corresponding one of 
the keep alive-messages without waiting for the aggregated reply packet to be received [Pereira, 
column 5, lines 45-47]. 
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See rejection of claim 1 for reasons to combine Ketcham with Pereira and Elliot. 
Claim 16 

Ketcham as modified by Pereira and Elliot discloses the aggregation device of claim 15, 
further comprising an encapsulator encapsulating said data in a packet suitable for transmission 
on said communication network {Pereira, column 2, lines 19-25, wherein encapsulation is 
inherent to PPP). 

Claim 22 

Ketcham as modified by Pereira and Elliot discloses the aggregation device of claim 21, 
further comprising second means for receiving an aggregated reply packet from said peer 
aggregation device {Ketcham, figure 4, inherently data packets can also flow from router 314 to 
router 308), wherein said aggregated reply packet indicates the status of at least some of said 
plurality of PPP sessions {Pereira, column 6, lines 1-6). 

Claim 23 

Ketcham as modified by Pereira and Elliot discloses the aggregation device of claim 22, 
further comprising means for sending a proxy keep-alive reply message to one of said plurality 
of end systems originating a corresponding one of said keep alive-messages without waiting for 
said aggregated reply packet {Pereira, column 5, lines 45-47). 

Claim 29 

Ketcham as modified by Pereira and Elliot discloses the aggregation device of claim 25, 
wherein said aggregation device comprises one of a network access server (NAS) and a home 
gateway implemented in a communication network {Ketcham, column 4, lines 37-43). 
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Claim 30 

Ketcham as modified by Pereira and Elliot discloses an aggregation device for 
processing an aggregated request packet, wherein said aggregated request packet is received 
from a peer aggregation device and indicates that the status of a plurality of point-to-point 
sessions are requested, said aggregation device comprising: 

an input interface receiving said aggregated request packet (Ketcham, figure 4, item 314, 
wherein the aggregated packet contains the poll requests as disclosed by Pereira); 

a de-encapsulator examining said aggregated request packet to determine that the status 
of said plurality of point-to-point sessions is requested (Ketcham, column 8, lines 15-22); 

a reply generator determining the status of each of said plurality of point-to-point 
sessions, and generating an aggregated reply packet indicating the status of each of said plurality 
of point-to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira's response polls may be 
aggregated at Ketcham' 's router 314); and 

an output interface sending said aggregated reply packet to said peer aggregation device 
(Ketcham, figure 4, inherently data packets can also flow from router 314 to router 308), wherein 
content of a remote status table is updated with the status of the PPP sessions, which have the 
peer aggregation device as an endpoint [Elliot, column 4 «lines 9-16» | column 5 «lines 15-22»: 
combining plural status messages into a single update message that is broadcast to other routers 
where the router is an endpoint of the link (i.e., session) to another router where each router 
represents an aggregation device which update tables remote from the routers], and wherein a 
proxy keep-alive reply message is sent to one of the plurality of end systems originating a 
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corresponding one of the keep alive-messages without waiting for the aggregated reply packet to 
be received [Pereira, column 5, lines 45-47]. 

See rejection of claim 1 for reasons to combine Ketcham with Pereira and Elliot. 

Claim 35 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 30, further 
comprising a keep-alive processor coupled to said de-encapsulator, wherein said keep-alive 
processor examines said aggregated request packet to determine that status of point-to-point 
sessions is requested and causes said reply generator to generate said aggregated reply packet 
{Ketcham, column 8, lines 15-22 and Pereira, column 6, lines 1-6). 

Claim 36 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 30, wherein 
said aggregation device comprises one of a network access server (NAS) and a home gateway 
implemented in a communication network {Ketcham, column 4, lines 37-43). 

Claim 42 

Ketcham as modified by Pereira and Elliot a computer-readable medium carrying one or 
more sequences of instructions for causing an aggregation device to process an aggregated 
request packet, wherein said aggregated request packet is received from a peer aggregation 
device and indicates that the status of a plurality of point-to-point sessions are requested, wherein 
execution of said one or more sequences of instructions by one or more processors contained in 
said aggregation device causes said one or more processors to perform the actions of: 
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examining said aggregated request packet to determine that the status of said plurality of 
point-to-point sessions is requested (Ketcham, column 8, lines 15-22, wherein the aggregated 
packet contains the poll requests as disclosed by Pereira); 

determining the status of each of said plurality of point-to-point sessions {Pereira, 
column 6, lines 1-6 and 50-55); 

generating an aggregated reply packet indicating the status of said plurality of point- to- 
point sessions {Pereira, column 6, lines 1-6, wherein Pereira's response polls may be aggregated 
at Ketcham' & router 314); 

sending said aggregated reply packet to said peer aggregation device {Ketcham, figure 4, 
inherently data packets can also flow from router 3 14 to router 308); 

receiving an aggregated reply packet from the peer aggregation device [Ketcham, column 
8, lines 15-22], wherein the aggregated reply packet indicates the status of at least some of the 
plurality of PPP sessions [Pereira, column 6, lines 1-6)], wherein content of a remote status table 
is updated with the status of the PPP sessions, which have the peer aggregation device as an 
endpoint [Elliot, column 4 «lines 9-16» | column 5 «lines 15-22»: combining plural status 
messages into a single update message that is broadcast to other routers where the router is an 
endpoint of the link (i.e., session) to another router where each router represents an aggregation 
device which update tables remote from the routers]; and 

sending a proxy keep-alive reply message to one of the plurality of end systems 
originating a corresponding one of the keep alive-messages without waiting for the aggregated 
reply packet to be received [Pereira, column 5, lines 45-47]. 

See rejection of claim 1 for reasons to combine Ketcham with Pereira and Elliot. 
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Claim 46 

Ketcham as modified by Pereira and Elliot the computer-readable medium of claim 42, 
wherein said aggregation device comprises one of a network access server (NAS) and a home 
gateway implemented in a communication network (Ketcham, column 4, lines 37-43). 

Claim 47 

Ketcham as modified by Pereira and Elliot a communication network comprising: 
a first aggregation device (Ketcham, figure 4, item 308) receiving a plurality of keep- 
alive messages (Pereira, column 4, lines 31-34) generated by a corresponding plurality of end 
systems, each of said plurality of keep-alive messages being designed to request the status of a 
corresponding point to point (PPP) session implemented on said communication network, said 
first aggregation device generating an aggregated request packet which includes data indicating 
that the status of said PPP sessions is requested (Ketcham, column 7, line 62 through column 8, 
line 4, wherein the aggregated packet contains the poll requests as disclosed by Pereira), and 
sending said aggregated request packet (Ketcham, column 7, line 62 through column 8, line 4); 
and 

a peer aggregation device (Ketcham, figure 4, item 314) receiving said aggregated request 
packet and indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira' s response polls may be aggregated at Ketcham' 's 
router 314), said peer aggregation packet sending said aggregated reply packet to said first 
aggregation device (Ketcham, figure 4, inherently data packets can also flow from router 314 to 
router 308), wherein each of said first aggregation device and said peer aggregation device is 
implemented as a single device (Ketcham, figure 4, items 308 and 314), wherein content of a 
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remote status table is updated with the status of the PPP sessions, which have the peer 
aggregation device as an endpoint [Elliot, column 4 «lines 9-16» | column 5 «lines 15-22»: 
combining plural status messages into a single update message that is broadcast to other routers 
where the router is an endpoint of the link (i.e., session) to another router where each router 
represents an aggregation device which update tables remote from the routers], and wherein a 
proxy keep-alive reply message is sent to one of the plurality of end systems originating a 
corresponding one of the keep alive-messages without waiting for the aggregated reply packet to 
be received [Pereira, column 5, lines 45-47]. 

See rejection of claim 1 for reasons to combine Ketcham with Pereira and Elliot. 

Claim 48 

Ketcham as modified by Pereira and Elliot the communication network of claim 47, 
wherein said first aggregation device is located at an edge of said communication networks 
{Ketcham, figure 4, item 308). 

Claim 49 

Ketcham as modified by Pereira and Elliot the communication network of claim 48, 
further comprising an access network coupling said first aggregation device to said 
corresponding plurality of end systems, wherein said plurality of keep-alive messages are 
received on said access network {Ketcham, figure 4, item 106). 

Claim 50 

Ketcham as modified by Pereira and Elliot the communication network of claim 49, 
wherein said first aggregation device and said peer aggregation device respectively comprise a 
network access server (NAS) and a home gateway {Ketcham, column 4, lines 37-43). 
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Claim 59 

Ketcham as modified by Pereira and Elliot the method of claim 1 , wherein said 
aggregation device is physically separate from said plurality of end systems {Ketcham, figure 4, 
item 308). 

Claim 60 

Ketcham as modified by Pereira and Elliot the method of claim 10, wherein said 
aggregation device is physically separate from said plurality of end systems {Ketcham, figure 4, 
item 308). 

Claim 69 

Ketcham as modified by Pereira and Elliot the method of claim 1 , wherein each of said 
PPP sessions terminates at a home gateway, and wherein said aggregation device comprises a 
switching device and is in the path of each of said PPP sessions from a corresponding one of said 
plurality of end systems to said home gateway {Ketcham, figure 4, item 308). 

Claim 72 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 30, wherein 
each of said PPP sessions terminates at a home gateway, and wherein said aggregation device 
comprises a switching device and is in the path of each of said PPP sessions from a 
corresponding one of said plurality of end systems to said home gateway {Ketcham, figure 4, 
item 314). 

Claim 75 

Ketcham as modified by Pereira and Elliot the computer readable medium of claim 37, 
wherein each of said PPP sessions terminates at a home gateway, and wherein said aggregation 
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device comprises a switching device and is in the path of each of said PPP sessions from a 
corresponding one of said plurality of end systems to said home gateway (Ketcham, figure 4, 
item 308). 

Claim 78 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 21, wherein 
each of said PPP sessions terminates at a home gateway, and wherein said aggregation device 
comprises a switching device and is in the path of each of said PPP sessions from a 
corresponding one of said plurality of end systems to said home gateway (Ketcham, figure 4, 
item 308). 

Claim 79 

Ketcham as modified by Pereira and Elliot the method of claim 1 , wherein said 
receiving, said generating and said sending are performed in an aggregation device implemented 
as a single device (Ketcham, figure 4, item 308). 

Claim 80 

Ketcham as modified by Pereira and Elliot the method of claim 10, wherein said 
examining, said determining, said generating and said sending are performed in said aggregation 
device implemented as a single device (Ketcham, figure 4, item 308). 

Claim 81 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 21, wherein 
said means for receiving, said means for generating and said means for sending are contained in 
said aggregation device implemented as a single device (Ketcham, figure 4, item 308). 
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Claim 82 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 25, wherein 
said means for examining, said means for determining, said means for generating and said means 
for sending are implemented in said aggregation device implemented as a single device 
{Ketcham, figure 4, item 308) 

Claim 83 

Ketcham as modified by Pereira and Elliot the aggregation device of claim 30, wherein 
said input interface, said de-encapsulator, said reply generator and said output interface are 
contained in said aggregation device implemented as a single device {Ketcham, figure 4, item 
308). 

Claim 84 

Ketcham as modified by Pereira and Elliot the computer readable medium of claim 37, 
wherein said receiving, said generating and said sending are performed by said aggregation 
device implemented as a single device {Ketcham, figure 4, item 308). 

Claim 85 

Ketcham as modified by Pereira and Elliot the computer readable medium of claim 42, 
wherein said examining, said determining, said generating and said sending are performed by 
said aggregation device implemented as a single device {Ketcham, figure 4, item 308). 
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B. Claims 13, 28, 32, 34, and 45 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over Ketcham, Pereira and Elliot, further in view of Chao et al. 
(U.S. Patent Number 5,964,837) "CW. 

Claim 13 

Ketcham, Pereira, Elliot and Chao discloses the method of claim 10, wherein said 
generating comprises setting a bit to one logical value to indicate that a corresponding one of 
said plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive {Chao, column 5, lines 50-53). 

Claim 28 

Ketcham, Pereira, Elliot and Chao discloses the aggregation device of claim 25, wherein 
said means for generating sets a bit in said aggregated reply packet to one logical value to 
indicate that a corresponding one of said plurality of sessions is OK/alive, and to another logical 
value to indicate that said corresponding one of said plurality of session not OK/alive {Chao, 
column 5, lines 50-53). 

Claim 32 

Ketcham, Pereira, Elliot and Chao discloses the aggregation device of claim 31, further 
comprising a session manager updating the status of said plurality of point-to-point sessions in 
said local status table {Chao, column 7, lines 64-66). 

Claim 34 

Ketcham, Pereira, Elliot and Chao discloses the aggregation device of claim 30, wherein 
said reply generator sets a bit in said aggregated reply packet to one logical value to indicate that 
a corresponding one of said plurality of sessions is OK/alive, and to another logical value to 
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indicate that said corresponding one of said plurality of session not OK/alive (Chao, column 5, 
lines 50-53). 

Claim 45 

Ketcham, Pereira, Elliot and Chao discloses the computer-readable medium of claim 42, 
wherein said generating comprises setting a bit to one logical value to indicate that a 
corresponding one of said plurality of sessions is OK/alive, and to another logical value to 
indicate that said corresponding one of said plurality of session not OK/alive {Chao, column 5, 
lines 50-53). 

C. Claims 12, 27, 33, and 44 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over Ketcham in view of Pereira, Elliot, and Chao, as applied 
above, further in view of Simpson ("RFC 1661: Point- to-Point Protocol," July 
1994). 

Claim 12 

Ketcham, Pereira, Elliot, Chao, and Simpson discloses the method of claim 10, wherein 
said generating comprises including a client magic number associated with each of said plurality 
of point-to-point sessions {Simpson, pages 45-47). 

Although the combination of Ketcham, Pereira, and Chao did not explicitly teach the use of 
a magic number associated with each session, Simpson taught a magic number for use with the 
point-to-point protocol. It would have been obvious to one of ordinary skill in the art at the time 
of the applicant's invention to modify the combination of Ketcham, Pereira, and Chao by adding 
a magic number as provided by Simpson. Again the combination satisfies the need for an 
improved method of monitoring a point-to-point network. See Chao, column 2, lines 15-24. 
This rationale also applies to other similar dependent claims utilizing the same combination. 
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Claim 27 

Ketcham, Pereira, Elliot, Chao, and Simpson discloses the aggregation device of claim 
25, wherein said means for generating includes a client magic number associated with each of 
said plurality of point-to-point sessions (Simpson, pages 45-47). 

Claim 33 

Ketcham, Pereira, Elliot, Chao, and Simpson discloses the aggregation device of claim 
30, wherein said reply generator includes in said aggregated reply packet a client magic number 
associated with each of said plurality of point-to-point sessions (Simpson, pages 45-47). 

Claim 44 

Ketcham, Pereira, Elliot, Chao, and Simpson discloses the computer-readable medium of 

claim 42, wherein said generating comprises including a client magic number associated with 

each of said plurality of point-to-point sessions (Simpson, pages 45-47). 

D. Claims 67, 68, 70, 71, 73, 74, 76, and 77 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Ketcham in view of Pereira and Elliot, as applied 
above, further in view of Rosenberg et al. ("An RTP Payload Format for User 
Multiplexing," May 1998), hereinafter referred to as Rosenberg. 

Claim 67 

Ketcham, Pereira, Elliot and Rosenberg discloses the method of claim 1, wherein said 
generating includes less data in said aggregated request packet than the data forming said 
plurality of keep-alive messages together (Rosenberg, page 2, paragraph beginning "On the other 
hand..."). 

Although the combination of Ketcham and Pereira did not explicitly state that the 
aggregated message contains less data than the plurality of the non-aggregated messages 
together, this is a well known result in message aggregation. This is evidenced by Rosenberg 
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whose system creates an aggregated message that is smaller than the sum of the original 
messages in order to improve packet efficiency. It would have been obvious to one of ordinary 
skill in the art at the time of the applicant's invention to modify the combination of Ketcham and 
Pereira by adding the ability for the message aggregator to generate less data in the aggregated 
message than the data forming the plurality of messages together as provided by Rosenberg. 
Here the combination satisfies the need for an improved connection oriented protocol for 
systems that maintain a number of end users that share a common link. See Pereira, column 4, 
lines 12-17. This rationale also applies to similar dependent claims utilizing the same 
combination. 

Claim 68 

Ketcham, Pereira, Elliot and Rosenberg discloses the method of claim 67, wherein each 
of said plurality of keep-alive messages contains an identifier of a corresponding PPP session, 
wherein said generating comprises: selecting said identifier of each of said plurality of keep-alive 
messages {Rosenberg, pages 3-5, section 2); and forming said aggregated request packet from 
said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request packet 
contains less data than said plurality of keep-alive messages together (Rosenberg, page 2, 
paragraph beginning "On the other hand. . ."). 

Claim 70 

Ketcham, Pereira, Elliot and Rosenberg discloses the aggregation device of claim 30, 
wherein said reply generator includes less data in said aggregated request packet than the data 
forming said plurality of keep-alive messages together (Rosenberg, page 2, paragraph beginning 
"On the other hand. . ."). 
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Claim 71 

Ketcham, Pereira, Elliot and Rosenberg discloses the aggregation device of claim 70, 
wherein each of said plurality of keep-alive messages contains an identifier of a corresponding 
PPP session, wherein said reply generator operates to: select said identifier of each of said 
plurality of keep-alive messages {Rosenberg, pages 3-5, section 2); and form said aggregated 
request packet from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated 
request packet contains less data than said plurality of keep-alive messages together (Rosenberg, 
page 2, paragraph beginning "On the other hand. . ."). 

Claim 73 

Ketcham, Pereira, Elliot and Rosenberg discloses the computer readable medium of 
claim 37, wherein said generating includes less data in said aggregated request packet than the 
data forming said plurality of keep-alive messages together (Rosenberg, page 2, paragraph 
beginning "On the other hand. . ."). 

Claim 74 

Ketcham, Pereira, Elliot and Rosenberg discloses the computer readable medium of 
claim 73, wherein each of said plurality of keep-alive messages contains an identifier of a 
corresponding PPP session, wherein said generating comprises: selecting said identifier of each 
of said plurality of keep-alive messages (Rosenberg, pages 3-5, section 2); and forming said 
aggregated request packet from said identifiers (Rosenberg, pages 3-5, section 2), whereby said 
aggregated request packet contains less data than said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand. . ."). 
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Claim 76 

Ketcham, Pereira, Elliot and Rosenberg discloses the aggregation device of claim 21, 
wherein said means for generating includes less data in said aggregated request packet than the 
data forming said plurality of keep-alive messages together (Rosenberg, page 2, paragraph 
beginning "On the other hand. . ."). 

Claim 77 

Ketcham, Pereira, Elliot and Rosenberg discloses the aggregation device of claim 76, 
wherein each of said plurality of keep-alive messages contains an identifier of a corresponding 
PPP session, wherein said means for generating operates to: select said identifier of each of said 
plurality of keep-alive messages (Rosenberg, pages 3-5, section 2); and form said aggregated 
request packet from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated 
request packet contains less data than said plurality of keep-alive messages together (Rosenberg, 
page 2, paragraph beginning "On the other hand. . ."). 

VIII. Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to DOHM CHANKONG whose telephone number is (571)272- 
3942. The examiner can normally be reached on Monday to Friday [10 am - 6 pm]. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Thu Nguyen can be reached on (571)272-6967. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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